Method, System, and Computer Program Product for Dynamic Development of an Application Programming Interface

ABSTRACT

A method for dynamic development of an application programming interface (API) including: receiving a first data file; generating an API configured to receive client data associated with a transaction message, where the generating the API includes: providing a data agnostic template; for each specific data parameter of the plurality of specific data parameters, assigning each template field with a corresponding specific data entry associated with the specific data parameter; and configuring a second user interface associated with the API by associating at least one display parameter with each specific data parameter of the plurality of specific data parameters; and displaying the second user interface such that a field displayed by the second user interface is configured to receive the data associated with each specific data parameter of the plurality of specific data parameters.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. patentapplication Ser. No. 16/210,294, filed Dec. 5, 2018, the disclosure ofwhich is hereby incorporated by reference in its entirety.

BACKGROUND 1. Field

The disclosure relates to development of an application programminginterface (API) and, in one non-limiting embodiment or aspect, to amethod, system, and computer program product for dynamic development ofan API, such as an API configured for onboarding a client by convertinga first data file of a client having a first format to a second datafile having a second format, which may be used to generate the API.

2. Technical Considerations

An application programming interface (API) may include a set ofsubroutine definitions, communication protocols, and/or tools forbuilding software. For example, an API may be a set of clearly definedmethods of communication between various components of a computer, acomputer system, a network of computers, and/or the like. In someinstances, an API may be used for a web-based computer system, acomputer operating system, database system, computer hardware, and/or asoftware library. An API may include an API specification that mayinclude specifications for routines, data structures, object classes,variables, and/or remote calls to be made by a computer.

In an electronic payment processing network, an acquirer system of anacquirer bank wishing to process transactions using a transactionprocessing system of a transaction service provider may undergo anonboarding process. The onboarding process may allow the acquirer systemto process transactions as a part of the electronic payment processingnetwork facilitated by the transaction service provider. Processing ofthe transaction may require the acquirer system to communicate staticdata that does not change for the acquirer system from transaction totransaction.

The above-described onboarding example may include a situation where anacquirer system is onboarded by reconfiguring stored data from a firstformat to a second format, and, for each example, the reconfiguring mayvary based on the client's initial data format (e.g., the first format).

Existing systems performing this onboarding process may include staticscreens (e.g., user interfaces). Reconfiguring the static screens toconform to the data received may require significant developmentefforts, which impacts the ultimate time required to completeonboarding. These existing systems may undergo a cumbersome developmentcycle in which, based on the first format of the data received from theclient, a suitable API must be developed.

SUMMARY

Accordingly, and generally, provided is an improved method, system, andcomputer program product for dynamic development of an applicationprogramming interface (API).

According to a non-limiting embodiment or aspect, a method for dynamicdevelopment of an API includes: receiving, with at least one processor,a first data file including a plurality of data entries, each data entryincluding a plurality of values of a plurality of specific dataparameters; generating, with at least one processor, an API configuredto receive client data associated with a transaction message, where thegenerating the API includes: providing a data agnostic templateincluding a first graphical user interface, the data agnostic templateincluding a plurality of data agnostic parameters, each data agnosticparameter including a template field, each template field configured toreceive a specific data entry associated with a specific data parameterof the plurality of specific data parameters; for each specific dataparameter of the plurality of specific data parameters, assigning eachtemplate field with a corresponding specific data entry associated withthe specific data parameter; and configuring a second user interfaceassociated with the API by associating at least one display parameterwith each specific data parameter of the plurality of specific dataparameters; and displaying, with at least one processor, the second userinterface, such that a field displayed by the second user interface isconfigured to receive the data associated with each specific dataparameter of the plurality of specific data parameters.

In one non-limiting embodiment or aspect, a specific data parameter ofthe plurality of specific data parameters may include a specific labelassociated with the specific data parameter. The plurality of specificdata parameters may include at least one data element associated withdata elements defined by ISO 8583. The plurality of specific dataparameters may include at least one data element associated with aclient identifier. The first data file may be associated with an a firstacquirer system, and the method may further include: receiving, with atleast one processor, the data associated with each specific dataparameter of the plurality of specific data parameters; based on thereceived data, generating, with at least one processor, a second datafile; generating, with at least one processor and based on the seconddata file, an API associated with the first acquirer system; receiving,with at least one processor, an abbreviated transaction message from thefirst acquirer system, the abbreviated transaction message associatedwith a payment transaction; and augmenting, with at least one processorand based on the API, the abbreviated transaction message with at leasta portion of the data from the second data file. The method may furtherinclude: receiving, with at least one processor, another data fileincluding a plurality of data entries, each data entry including aplurality of second specific data parameters, the second specific dataparameters different from the specific data parameters associated withthe first data file; and using the data agnostic template to display auser interface configured to receive client data associated with eachsecond specific data parameter of the plurality of second specific dataparameters. The first data file may be received by a transactionprocessing system of a transaction service provider from an issuersystem of an issuer bank or an acquirer system of an acquirer.

According to a non-limiting embodiment or aspect, a system for dynamicdevelopment of an API includes at least one processor programmed orconfigured to: receive a first data file including a plurality of dataentries, each data entry including a plurality of values of a pluralityof specific data parameters; generate an API configured to receiveclient data associated with a transaction message by: providing a dataagnostic template including a first graphical user interface, the dataagnostic template including a plurality of data agnostic parameters,each data agnostic parameter including a template field, each templatefield configured to receive a specific data entry associated with aspecific data parameter of the plurality of specific data parameters;for each specific data parameter of the plurality of specific dataparameters, assigning each template field with a corresponding specificdata entry associated with the specific data parameter; and configuringa second user interface associated with the API by associating at leastone display parameter with each specific data parameter of the pluralityof specific data parameters; and display the second user interface, suchthat a field displayed by the second user interface is configured toreceive the data associated with each specific data parameter of theplurality of specific data parameters.

In one non-limiting embodiment or aspect, a specific data parameter ofthe plurality of specific data parameters may include a specific labelassociated with the specific data parameter. The plurality of specificdata parameters may include at least one data element associated withdata elements defined by ISO 8583. The plurality of specific dataparameters may include at least one data element associated with aclient identifier. The first data file may be associated with an a firstacquirer system, and the at least one processor may be programmed orconfigured to: receive the data associated with each specific dataparameter of the plurality of specific data parameters; based on thereceived data, generate a second data file; generate, based on thesecond data file, an API associated with the first acquirer system;receive an abbreviated transaction message from the first acquirersystem, the abbreviated transaction message associated with a paymenttransaction; and augment, based on the API, the abbreviated transactionmessage with at least a portion of the data from the second data file.The first data file may be associated with a first acquirer system, andthe one or more instructions may cause the at least one processor to:receive the data associated with each specific data parameter of theplurality of specific data parameters; based on the received data,generate a second data file; generate, based on the second data file, anAPI associated with the first acquirer system; receive an abbreviatedtransaction message from the first acquirer system, the abbreviatedtransaction message associated with a payment transaction; and augment,based on the API, the abbreviated transaction message with at least aportion of the data from the second data file. The at least oneprocessor may be programmed or configured to: receive another data fileincluding a plurality of data entries, each data entry including aplurality of second specific data parameters, the second specific dataparameters different from the specific data parameters associated withthe first data file; and use the data agnostic template to display auser interface configured to receive data associated with each secondspecific data parameter of the plurality of second specific dataparameters. The first data file may be received by a transactionprocessing system of a transaction service provider from an issuersystem of an issuer bank or an acquirer system of an acquirer.

According to a non-limiting embodiment or aspect, a computer programproduct for dynamic development of an application programming interface(API), the computer program product including at least onenon-transitory computer-readable medium including one or moreinstructions that, when executed by at least one processor, cause the atleast one processor to: receive a first data file including a pluralityof data entries, each data entry including a plurality of values of aplurality of specific data parameters; generate an API configured toreceive client data associated with a transaction message by: providinga data agnostic template including a first graphical user interface, thedata agnostic template including a plurality of data agnosticparameters, each data agnostic parameter including a template field,each template field configured to receive a specific data entryassociated with a specific data parameter of the plurality of specificdata parameters; for each specific data parameter of the plurality ofspecific data parameters, assigning each template field with acorresponding specific data entry associated with the specific dataparameter; and configuring a second user interface associated with theAPI by associating at least one display parameter with each specificdata parameter of the plurality of specific data parameters; and displaythe second user interface, such that a field displayed by the seconduser interface is configured to receive the data associated with eachspecific data parameter of the plurality of specific data parameters.

In one non-limiting embodiment or aspect, a specific data parameter ofthe plurality of specific data parameters may include a specific labelassociated with the specific data parameter. The plurality of specificdata parameters may include at least one data element associated withdata elements defined by ISO 8583. The plurality of specific dataparameters may include at least one data element associated with aclient identifier. The one or more instructions may cause the at leastone processor to: in response to displaying the second user interface,convert, using the generated API, the first data file into a converteddata file having a predetermined second format. The one or moreinstructions may cause the at least one processor to: receive anotherdata file including a plurality of data entries, each data entryincluding a plurality of second specific data parameters, the secondspecific data parameters different from the specific data parametersassociated with the first data file; and use the data agnostic templateto display a user interface configured to receive client data associatedwith each second specific data parameter of the plurality of secondspecific data parameters. The first data file may be received by atransaction processing system of a transaction service provider from anissuer system of an issuer bank or an acquirer system of an acquirer.

Further embodiments or aspects are set forth in the following numberedclauses:

Clause 1: A method for dynamic development of an application programminginterface (API) comprising: receiving, with at least one processor, afirst data file comprising a plurality of data entries, each data entrycomprising a plurality of values of a plurality of specific dataparameters; generating, with at least one processor, an API configuredto receive client data associated with a transaction message, whereinthe generating the API comprises: providing a data agnostic templateincluding a first graphical user interface, the data agnostic templatecomprising a plurality of data agnostic parameters, each data agnosticparameter comprising a template field, each template field configured toreceive a specific data entry associated with a specific data parameterof the plurality of specific data parameters; for each specific dataparameter of the plurality of specific data parameters, assigning eachtemplate field with a corresponding specific data entry associated withthe specific data parameter; and configuring a second user interfaceassociated with the API by associating at least one display parameterwith each specific data parameter of the plurality of specific dataparameters; and displaying, with at least one processor, the second userinterface, such that a field displayed by the second user interface isconfigured to receive the data associated with each specific dataparameter of the plurality of specific data parameters.

Clause 2: The method of clause 1, wherein a specific data parameter ofthe plurality of specific data parameters comprises a specific labelassociated with the specific data parameter.

Clause 3: The method of clause 1 or 2, wherein the plurality of specificdata parameters comprise at least one data element associated with dataelements defined by ISO 8583.

Clause 4: The method of any of clauses 1-3, wherein the plurality ofspecific data parameters comprise at least one data element associatedwith a client identifier.

Clause 5: The method of any of clauses 1-4, wherein the first data fileis associated with a first acquirer system, the method furthercomprising: receiving, with at least one processor, the data associatedwith each specific data parameter of the plurality of specific dataparameters; based on the received data, generating, with at least oneprocessor, a second data file; generating, with at least one processorand based on the second data file, an API associated with the firstacquirer system; receiving, with at least one processor, an abbreviatedtransaction message from the first acquirer system, the abbreviatedtransaction message associated with a payment transaction; andaugmenting, with at least one processor and based on the API, theabbreviated transaction message with at least a portion of the data fromthe second data file.

Clause 6: The method of any of clauses 1-5, further comprising:receiving, with at least one processor, another data file comprising aplurality of data entries, each data entry comprising a plurality ofsecond specific data parameters, the second specific data parametersdifferent from the specific data parameters associated with the firstdata file; and using the data agnostic template to display a userinterface configured to receive client data associated with each secondspecific data parameter of the plurality of second specific dataparameters.

Clause 7: The method of any of clauses 1-6, wherein the first data fileis received by a transaction processing system of a transaction serviceprovider from an issuer system of an issuer bank or an acquirer systemof an acquirer.

Clause 8: A system for dynamic development of an application programminginterface (API) comprising at least one processor programmed orconfigured to: receive a first data file comprising a plurality of dataentries, each data entry comprising a plurality of values of a pluralityof specific data parameters; generate an API configured to receiveclient data associated with a transaction message by: providing a dataagnostic template including a first graphical user interface, the dataagnostic template comprising a plurality of data agnostic parameters,each data agnostic parameter comprising a template field, each templatefield configured to receive a specific data entry associated with aspecific data parameter of the plurality of specific data parameters;for each specific data parameter of the plurality of specific dataparameters, assigning each template field with a corresponding specificdata entry associated with the specific data parameter; and configuringa second user interface associated with the API by associating at leastone display parameter with each specific data parameter of the pluralityof specific data parameters; and display the second user interface, suchthat a field displayed by the second user interface is configured toreceive the data associated with each specific data parameter of theplurality of specific data parameters.

Clause 9: The system of clause 8, wherein a specific data parameter ofthe plurality of specific data parameters comprises a specific labelassociated with the specific data parameter.

Clause 10: The system of clause 8 or 9, wherein the plurality ofspecific data parameters comprise at least one data element associatedwith data elements defined by ISO 8583.

Clause 11: The system of any of clauses 8-10, wherein the plurality ofspecific data parameters comprise at least one data element associatedwith a client identifier.

Clause 12: The system of any of clauses 8-11, wherein the first datafile is associated with a first acquirer system and the at least oneprocessor is programmed or configured to: receive the data associatedwith each specific data parameter of the plurality of specific dataparameters; based on the received data, generate a second data file;generate, based on the second data file, an API associated with thefirst acquirer system; receive an abbreviated transaction message fromthe first acquirer system, the abbreviated transaction messageassociated with a payment transaction; and augment, based on the API,the abbreviated transaction message with at least a portion of the datafrom the second data file.

Clause 13: The system of any of clauses 8-12, wherein the at least oneprocessor is programmed or configured to: receive another data filecomprising a plurality of data entries, each data entry comprising aplurality of second specific data parameters, the second specific dataparameters different from the specific data parameters associated withthe first data file; and use the data agnostic template to display auser interface configured to receive client data associated with eachsecond specific data parameter of the plurality of second specific dataparameters.

Clause 14: The system of any of clauses 8-13, wherein the first datafile is received by a transaction processing system of a transactionservice provider from an issuer system of an issuer bank or an acquirersystem of an acquirer.

Clause 15: A computer program product for dynamic development of anapplication programming interface (API), the computer program productcomprising at least one non-transitory computer-readable mediumincluding one or more instructions that, when executed by at least oneprocessor, cause the at least one processor to: receive a first datafile comprising a plurality of data entries, each data entry comprisinga plurality of values of a plurality of specific data parameters;generate an API configured to receive client data associated with atransaction message by: providing a data agnostic template including afirst graphical user interface, the data agnostic template comprising aplurality of data agnostic parameters, each data agnostic parametercomprising a template field, each template field configured to receive aspecific data entry associated with a specific data parameter of theplurality of specific data parameters; for each specific data parameterof the plurality of specific data parameters, assigning each templatefield with a corresponding specific data entry associated with thespecific data parameter; and configuring a second user interfaceassociated with the API by associating at least one display parameterwith each specific data parameter of the plurality of specific dataparameters; and display the second user interface, such that a fielddisplayed by the second user interface is configured to receive the dataassociated with each specific data parameter of the plurality ofspecific data parameters.

Clause 16: The computer program product of clause 15, wherein a specificdata parameter of the plurality of specific data parameters comprises aspecific label associated with the specific data parameter.

Clause 17: The computer program product of clause 15 or 16, wherein theplurality of specific data parameters comprise at least one data elementassociated with data elements defined by ISO 8583.

Clause 18: The computer program product of any of clauses 15-17, whereinthe plurality of specific data parameters comprise at least one dataelement associated with a client identifier.

Clause 19: The computer program product of any of clauses 15-18, whereinthe first data file is associated with a first acquirer system and theone or more instructions cause the at least one processor to: receivethe data associated with each specific data parameter of the pluralityof specific data parameters; based on the received data, generate asecond data file; generate, based on the second data file, an APIassociated with the first acquirer system; receive an abbreviatedtransaction message from the first acquirer system, the abbreviatedtransaction message associated with a payment transaction; and augment,based on the API, the abbreviated transaction message with at least aportion of the data from the second data file.

Clause 20: The computer program product of any of clauses 15-19, whereinthe one or more instructions cause the at least one processor to:receive another data file comprising a plurality of data entries, eachdata entry comprising a plurality of second specific data parameters,the second specific data parameters different from the specific dataparameters associated with the first data file; and use the dataagnostic template to display a user interface configured to receiveclient data associated with each second specific data parameter of theplurality of second specific data parameters.

Clause 21: The computer program product of any of clauses 15-20, whereinthe first data file is received by a transaction processing system of atransaction service provider from an issuer system of an issuer bank oran acquirer system of an acquirer.

These and other features and characteristics of the present disclosure,as well as the methods of operation and functions of the relatedelements of structures and the combination of parts and economies ofmanufacture, will become more apparent upon consideration of thefollowing description and the appended claims with reference to theaccompanying drawings, all of which form a part of this specification,wherein like reference numerals designate corresponding parts in thevarious figures. It is to be expressly understood, however, that thedrawings are for the purpose of illustration and description only andare not intended as a definition of the limits of the disclosure. Asused in the specification and the claims, the singular form of “a,”“an,” and “the” include plural referents unless the context clearlydictates otherwise.

BRIEF DESCRIPTION OF THE DRAWINGS

Additional advantages and details of the disclosure are explained ingreater detail below with reference to the non-limiting exemplaryembodiments that are illustrated in the accompanying schematic figures,in which:

FIG. 1 shows a schematic view of one non-limiting embodiment or aspectof an existing electronic payment processing network;

FIG. 2A shows a schematic view of a system for onboarding by dynamicallydeveloping an application programming interface (API) according to anon-limiting embodiment or aspect;

FIG. 2B shows a schematic view of an augmentation system for processingtransaction using the API according to a non-limiting embodiment oraspect;

FIG. 3A shows a schematic of a first file according to a non-limitingembodiment or aspect;

FIG. 3B shows a schematic of a second file according to a non-limitingembodiment or aspect;

FIG. 4A shows a schematic of a first graphical user interface displayinga data agnostic template according to a non-limiting embodiment oraspect;

FIG. 4B shows a schematic of the first graphical user interface fromFIG. 4A having several of the template fields of the data agnostictemplate assigned with a corresponding specific data entry associatedwith a specific data parameter according to a non-limiting embodiment oraspect;

FIG. 5 shows a schematic of a display configuration screen according toa non-limiting embodiment or aspect;

FIG. 6 shows a schematic of a second user interface according to anon-limiting embodiment or aspect;

FIG. 7A shows a schematic of another first file according to anon-limiting embodiment or aspect;

FIG. 7B shows a schematic of another second file according to anon-limiting embodiment or aspect;

FIG. 8 shows a step diagram of a method for dynamic development of anAPI according to a non-limiting embodiment or aspect; and

FIG. 9 shows a step diagram of a non-limiting embodiment or aspect of amethod for generating an API according to a non-limiting embodiment oraspect.

DETAILED DESCRIPTION

For purposes of the description hereinafter, the terms “end,” “upper,”“lower,” “right,” “left,” “vertical,” “horizontal,” “top,” “bottom,”“lateral,” “longitudinal,” and derivatives thereof shall relate to thedisclosure as it is oriented in the drawing figures. However, it is tobe understood that the disclosure may assume various alternativevariations and step sequences, except where expressly specified to thecontrary. It is also to be understood that the specific devices andprocesses illustrated in the attached drawings, and described in thefollowing specification, are simply exemplary embodiments or aspects ofthe disclosure. Hence, specific dimensions and other physicalcharacteristics related to the embodiments or aspects disclosed hereinare not to be considered as limiting.

As used herein, the terms “communication” and “communicate” may refer tothe reception, receipt, transmission, transfer, provision, and/or thelike, of information (e.g., data, signals, messages, instructions,commands, and/or the like). For one unit (e.g., a device, a system, acomponent of a device or system, combinations thereof, and/or the like)to be in communication with another unit means that the one unit is ableto directly or indirectly receive information from and/or transmitinformation to the other unit. This may refer to a direct or indirectconnection (e.g., a direct communication connection, an indirectcommunication connection, and/or the like) that is wired and/or wirelessin nature. Additionally, two units may be in communication with eachother even though the information transmitted may be modified,processed, relayed, and/or routed between the first and second unit. Forexample, a first unit may be in communication with a second unit eventhough the first unit passively receives information and does notactively transmit information to the second unit. As another example, afirst unit may be in communication with a second unit if at least oneintermediary unit (e.g., a third unit located between the first unit andthe second unit) processes information received from the first unit andcommunicates the processed information to the second unit. In somenon-limiting embodiments, a message may refer to a network packet (e.g.,a data packet, and/or the like) that includes data. It will beappreciated that numerous other arrangements are possible.

As used herein, the term “transaction service provider” may refer to anentity that receives transaction authorization requests from merchantsor other entities and provides guarantees of payment, in some casesthrough an agreement between the transaction service provider and anissuer institution. For example, a transaction service provider mayinclude a payment network such as Visa® or any other entity thatprocesses transactions. The term “transaction processing system” mayrefer to one or more computer systems operated by or on behalf of atransaction service provider, such as a transaction processing serverexecuting one or more software applications. A transaction processingsystem may include one or more processors and, in some non-limitingembodiments, may be operated by or on behalf of a transaction serviceprovider.

As used herein, the term “issuer institution” or “issuer” may refer toone or more entities, such as a bank, that provide accounts to customersfor conducting transactions (e.g., payment transactions), such asinitiating credit and/or debit payments. For example, an issuerinstitution may provide an account identifier, such as a personalaccount number (PAN), to a customer that uniquely identifies one or moreaccounts associated with that customer. The account identifier may beembodied on a payment device, such as a physical financial instrument,e.g., a payment card, and/or may be electronic and used for electronicpayments. The term “issuer system” refers to one or more computersystems operated by or on behalf of an issuer institution, such as aserver computer executing one or more software applications. Forexample, an issuer system may include one or more authorization serversfor authorizing a transaction.

As used herein, the term “acquirer institution” or “acquirer” may referto an entity licensed and/or approved by the transaction serviceprovider to originate transactions (e.g., payment transactions) using apayment device associated with the transaction service provider. Thetransactions the acquirer institution may originate may include paymenttransactions (e.g., purchases, original credit transactions (OCTs),account funding transactions (AFTs), and/or the like). In somenon-limiting embodiments, an acquirer institution may be a financialinstitution, such as a bank. As used herein, the term “acquirer system”may refer to one or more computer systems, computer devices, softwareapplications, and/or the like operated by or on behalf of an acquirerinstitution.

As used herein, the term “account identifier” may include one or morePANs, tokens, or other identifiers associated with a customer account.The term “token” may refer to an identifier that is used as a substituteor replacement identifier for an original account identifier, such as aPAN. Account identifiers may be alphanumeric or any combination ofcharacters and/or symbols. Tokens may be associated with a PAN or otheroriginal account identifier in one or more data structures (e.g., one ormore databases, and/or the like) such that they may be used to conduct atransaction without directly using the original account identifier. Insome non-limiting embodiments, an original account identifier, such as aPAN, may be associated with a plurality of tokens for differentindividuals or purposes.

As used herein, the term “merchant” may refer to an individual or entitythat provides goods and/or services, or access to goods and/or services,to customers based on a transaction, such as a payment transaction. Theterm “merchant” or “merchant system” may also refer to one or morecomputer systems operated by or on behalf of a merchant, such as aserver computer executing one or more software applications. A“point-of-sale (POS) system,” as used herein, may refer to one or morecomputers and/or peripheral devices used by a merchant to engage inpayment transactions with customers, including one or more card readers,near-field communication (NFC) receivers, radio frequency identification(RFID) receivers, and/or other contactless transceivers or receivers,contact-based receivers, payment terminals, computers, servers, inputdevices, and/or other like devices that can be used to initiate apayment transaction.

As used herein, the term “payment device” may refer to a payment card(e.g., a credit or debit card), a gift card, a smartcard, smart media, apayroll card, a healthcare card, a wrist band, a machine-readable mediumcontaining account information, a keychain device or fob, an RFIDtransponder, a retailer discount or loyalty card, a security card, anaccess card, a wireless terminal, a transponder, and/or the like. Insome non-limiting embodiments, the payment device may include volatileor non-volatile memory to store information (e.g., an accountidentifier, a name of the account holder, and/or the like).

As used herein, the term “server” may refer to or include one or moreprocessors or computers, storage devices, or similar computerarrangements that are operated by or facilitate communication andprocessing for multiple parties in a network environment, such as theinternet, although it will be appreciated that communication may befacilitated over one or more public or private network environments andthat various other arrangements are possible. Further, multiplecomputers, e.g., servers, or other computerized devices, e.g.,point-of-sale devices, directly or indirectly communicating in thenetwork environment may constitute a “system,” such as a merchant'spoint-of-sale system. Reference to “a server” or “a processor,” as usedherein, may refer to a previously-recited server and/or processor thatis recited as performing a previous step or function, a different serverand/or processor, and/or a combination of servers and/or processors. Forexample, as used in the specification and the claims, a first serverand/or a first processor that is recited as performing a first step orfunction may refer to the same or different server and/or a processorrecited as performing a second step or function.

As used herein, the term “computing device” may refer to one or moreelectronic devices that are configured to directly or indirectlycommunicate with or over one or more networks. The computing device maybe a mobile device. As an example, a mobile device may include acellular phone (e.g., a smartphone or standard cellular phone), aportable computer, a wearable device (e.g., watches, glasses, lenses,clothing, and/or the like), a personal digital assistant (PDA), and/orother like devices. In other non-limiting embodiments, the computingdevice may be a desktop computer or other non-mobile computer.Furthermore, the term “computer” may refer to any computing device thatincludes the necessary components to receive, process, and output data,and normally includes a display, a processor, a memory, an input device,and a network interface. An “application” or “application programinterface” (API) refers to computer code or other data sorted on acomputer-readable medium that may be executed by a processor tofacilitate the interaction between software components, such as aclient-side front-end and/or server-side back-end for receiving datafrom the client. An “interface” refers to a generated display, such asone or more graphical user interfaces (GUIs) with which a user mayinteract, either directly or indirectly (e.g., through a keyboard,mouse, etc.).

Non-limiting embodiments or aspects of the present disclosure aredirected to a method, system, and computer program products for dynamicdevelopment of an application programming interface (API). Non-limitingembodiments or aspects include a data agnostic template that reduces thetime required to onboard a client. The data agnostic template may reducethe time required to onboard a client by reducing or eliminating theamount of hardcoding required by the developer to convert the first datafile from the first format to the second data file having a secondformat. By utilizing a metadata-driven flexible framework the onboardingparameters can be easily and quickly added, removed, or modified toconvert the first data file having the first format to the second datafile having the second format. In this way, the flexibility of themetadata driven flexible framework of the data agnostic template allowsthe system to handle data submitted by the client to the system in anyformat, as well as any type of data submitted by the client to thesystem. Further, processing resources required to complete theonboarding process (e.g., convert the first file to the reconfiguredsecond file) are advantageously reduced. In addition, themetadata-driven flexible framework of the present disclosure also allowsfor quicker, more efficient modification of existing,previously-developed APIs for onboarding.

Referring to FIG. 1, an existing electronic payment processing network10 is shown in which a payment transaction between a consumer 12 and amerchant is processed. To initiate the payment transaction, the consumer12 presents a payment device (e.g., credit card) to a merchant system 14(e.g., merchant POS device) operated by or on behalf of the merchant.The merchant system 14 communicates a transaction message to an acquirersystem 15 (e.g., a merchant bank) of the merchant. The acquirer system15 communicates the transaction message to the transaction processingsystem (TPS) 16 operated by or on behalf of the transaction serviceprovider associated with the consumer's 12 payment device to requestthat the payment transaction be processed. The TPS 16 communicates anauthorization request to an issuer system 18 operated by or on behalf ofthe issuer who issued the payment device to the consumer 12. Theauthorization request conforms to ISO 8583 in its format. In response tothe authorization request, the issuer system 18 makes an authorizationdecision as to whether the payment transaction is to be approved ordeclined. The issuer system 18 communicates an authorization responsecontaining the authorization decision to the TPS 16, and theauthorization response conforms to ISO 8583 in its format. The TPS 16then communicates the authorization response to the acquirer system 15which, in turn, communicates the authorization response to the merchantsystem 14, which is subsequently conveyed to the consumer 12.

In order for the acquirer system 15 and/or the issuer system 18 toparticipate in the electronic payment processing network 10 facilitatedby the TPS 16, the TPS 16 may store certain data associated with theacquirer system 15 and/or issuer system 18. The TPS 16 may store thisdata in a predetermined format, such that the authorization message canbe communicated according to the ISO 8583 format. The predeterminedformat may be different from the format in which the data is stored onthe acquirer system 15 and/or the issuer system 18. To participate inthe electronic payment processing network 10 facilitated by the TPS 16,the issuer system 18 and/or acquirer system 15 may be onboarded with theTPS 16. The onboarding process may be performed as described herein. Insome non-limiting embodiments, the information received from theacquirer system 15 and/or the issuer system 18 as part of the onboardingprocess may include static data that is the same for each paymenttransaction in which that acquirer system 15 and/or the issuer system 18is involved with processing.

Referring to FIG. 2A, a system 19 for onboarding the acquirer system 15with the TPS 16 is shown. The system 19 includes the TPS 16 and theacquirer system 15. Additionally or alternatively, the system 19 mayfurther include an onboarding system 20 operated by or on behalf of thetransaction service provider or other third party entity. In somenon-limiting embodiments, the onboarding system 20 may be a component ofthe TPS 16.

With continued reference to FIG. 2A, the acquirer system 15 may includea first data file 22 that includes data, and the acquirer system 15 maycommunicate the first data file 22 to the onboarding system 20. In somenon-limiting examples, the acquirer system 15 communicates the firstdata file 22 without performing any reformatting or reconfiguration ofthe first data file, such that the first data file 22 is communicatedexactly as it exists on the acquirer system 15.

With continued reference to FIG. 2A, the onboarding system 20 maygenerate a second data file 24 in response to receiving the first datafile 22. The second data file 24 may include at least a portion of thedata from the first data file 22, although that data may be rearranged,reformatted, relabeled, or otherwise edited. In some non-limitingembodiments, generating the second data file 24 may include generating anew file and storing at least a portion of the data from the first datafile 22 to the newly generated second data file 24. In othernon-limiting embodiments, generating the second data file 24 may includeediting the existing first data file 22, such that the first data file22 is reconfigured to constitute the second data file 24.

In some non-limiting embodiments, the second data file 24 may include atleast a portion of the data from the first data file 22. In somenon-limiting embodiments, certain data from the first data file 22 maybe directly included in the second data file 24 without any alterations.In some non-limiting embodiments, certain data from the first data file22 may be relabeled and included in the second data file 24 (e.g., thedata given a different heading in a table). In some non-limitingembodiments, certain data from the first data file 22 may be mergedtogether and included in the second data file 24 (e.g., separate firstname and last name columns in a first data file 22 may be merged into asingle “Name” column in the second data file 24). In some non-limitingembodiments, certain data from the first data file 22 may be split apartand included in the second data file 24 (e.g., a single “Name” column ina first data file 22 may be split into separate first name and last namecolumns in the second data file 24). In some non-limiting embodiments,certain data from the first data file 22 may be reformatted and includedin the second data file 24 (e.g., a date in the format 01.01.2018 in thefirst data file 22 may be reformatted to 01/01/2018 in the second datafile 24). Certain data from the first data file 22 may be omittedaltogether from the second data file 24. The data from the first datafile 22 may be rearranged, reformatted, relabeled, or otherwise editedand included in the second data file in any other suitable way. Certaindata not included in the first data file 22 may be included in thesecond data file 24 (e.g., an identifier may be added to associate thedata in the second data file 24 with the system communicating the firstdata file 22 to the onboarding system 20).

In response to generating the second data file 24, the onboarding system20 may communicate the second data file 24 to the TPS 16. The TPS 16 maystore the second data file 24 and utilize the second data file 24 fordownstream processing, such as processing payment transactions with theacquirer system 15 in the electronic payment processing network 10 shownin FIG. 2B. In this way, communicate of the second data file 24 to theTPS 16 to generate the API, which is executed by a processor or otherhardware, for instance, an augmenting system 25 as shown in FIG. 2B.

Referring to FIG. 3A, a non-limiting embodiment of the first data file222 is shown. The first data file 122 may include a plurality of dataentries 126, and each data entry 126 may include a plurality of valuesof specific data parameters 130. In other words, the first row of thefirst data file 122 table includes the specific data parameters 130,which are column headings of the table, and subsequent rows include dataentries 126 in the table for the specific data parameters 130. Each dataentry 126 includes client data 128 associated with each specific dataparameter 130. As one non-limiting example from the first data file 122shown in FIG. 3A, “Merchant ID” is a specific data parameter 130, and inthe first data entry, the client data 128 associated with “Merchant” is“0001”.

Referring to FIG. 3B, a non-limiting embodiment of the second data file124 converted from the first data file 122 is shown. The second datafile 124 includes at least a portion of the data from the first datafile 122. For example, the data associated with “Acquirer BIN” from thefirst data file 122 is included in the second data file 124. Moreover,the data associated with “Acquirer Country Code” from the first datafile 122 is included in the second data file 124. New data labeled“Client ID” in the second data file 124 was not previously included inthe first data file 122 and constitutes an identifier associated withthe acquirer system 15 (a client identifier) communicating the firstdata file 122 or a merchant associated with the acquirer system 15. Inthis way, the second data file 124 includes at least a portion of thedata from the first data file 122, although that data may be rearranged,reformatted, relabeled, or otherwise edited.

In response to receiving the first data file 122, the onboarding system20 may generate the second data file 224, which may be communicated todownstream system (e.g., the augmentation system 25 of FIG. 2B) to causean API to be generated. The second data file 224 used to create the APImay be generated as described below in association with FIGS. 4A-6.

Referring to FIGS. 4A and 4B, a data agnostic template 32 displayed on afirst graphical user interface (GUI) 34 is shown according to anon-limiting embodiment or aspect. It will be appreciated that differentlayouts of the data agnostic template 32 and first GUI 34 are alsocontemplated under this disclosure. The data agnostic template 32 mayinclude a plurality of data agnostic parameters 36. The data agnosticparameters 36 may each include a template field 38. In FIG. 4A, thetemplate fields 38 are empty and are configured to receive a specificdata entry associated with a specific data parameter 130. In FIG. 4B,for each specific data parameter 130, each template field 38 is assigneda corresponding specific data entry 40 associated with the specific dataparameter 130. In this non-limiting example, at least one of thespecific data parameters may include a data element associated with dataelements defined by ISO 8583 (e.g., data fields 1-128 of the ISO-defineddata elements).

Referring to FIGS. 3A, 3B, and 4B, in the example shown in FIG. 4B, thespecific data parameter 130 entered from the first data file 122 is“Acquirer BIN”. In FIG. 4B, “Acquirer BIN” is entered into the templatefield 38 associated with the data agnostic parameter 36 entitled“Extract Field Name”, which corresponds to the title of the specificdata parameter 130 from the first data file 122. Under the data agnosticparameter 36 entitled “Field Name”, the labeled specific data parameter130 of “Acquirer BIN” is included as the template field 38 as thecorresponding specific data entry 40 associated with the specific dataparameter 130. Other data agnostic parameters may be included in thedata agnostic template 32, such as “Field Label” (label for theparticular “Field Name” on the later described GUI), “Field Type” (e.g.,whether the field contains numbers, characters, some combinationthereof, or the like), “Max Field Length” (e.g., count of the maximumnumber of numbers and/or characters associated with the client data),and the like. It will be appreciated that additional data agnosticparameters 36 may be included.

With continued reference to FIGS. 4A and 4B, any number of specific dataparameters 130 may be entered into the data agnostic template 32. In onenon-limiting example, the specific data parameters 130 are entered oneat a time into the data agnostic template 32 until each relevantspecific data parameter has been entered into the data agnostic template32 such that the second file used to generate the API can be generated.

Referring to FIG. 5, a display configuration screen 42 is shown. Thedisplay configuration screen 42 may appear after each specific dataparameters 130 has been entered into the data agnostic template. Forexample, in FIG. 5, four separate specific data parameters 130 wereentered into the data agnostic template 32 (i.e., “Client ID”, “AcquirerBIN”, “Acquirer Country Code”, and “Acquirer Business ID”).

With continued reference to FIG. 5, the display configuration screen 42may be used to configure a second GUI (e.g., the second GUI 45 in FIG.6). The configuration may be effected by associating at least onedisplay parameter 44 with each specific data parameter 130. The displayparameters 44 may determine how the specific data parameters 130 arearranged on the second GUI 45. Non-limiting examples of displayparameters include a parameter for whether an entry must be associatedwith the specific data parameters 130, whether a warning is to begenerated for an entry associate with the specific data parameter 130that is blank, whether the specific data parameter 130 is associatedwith an updateable field, the order and configuration of the specificdata parameters 130 on the second GUI 45, and the like.

Referring to FIG. 6, the second GUI 45 is shown according to onenon-limiting embodiment or aspect. On the second GUI 45, the specificdata parameters 130 are arranged as configured from the displayconfiguration screen 42. The second GUI may include client data fields46 that are configured to receive the client data 128 associated witheach specific data parameter 130. The second GUI 45 may receive theclient data associated with each specific data parameter 130 for eachdata entry 126, such that all of the relevant client data 128 from thefirst data file 122 is onboarded by the onboarding system 20 bygenerating the second data file 124. The second GUI may automaticallyreceive the client data 128 from the first data file 122, such that oncethe second file is generated, it may be communicated to the a systemthat will generate an API dynamically based on that second data file124.

Referring back to FIGS. 3A-6, as previously described, an API may bedynamically generated based on the second data file 124 generated by theonboarding system 20 based on the data contained in the first data file122. The generated API may be specific to that particular acquirersystem 15. An API may be generated for other acquirer systems in thissame manner so as to not require an onboarding API be hardcoded fromscratch, saving processing resources and reducing onboarding time.

Referring back to FIG. 2B a non-limiting embodiment or aspect of amethod for processing transactions using an augmentation system 25 thatexecutes the dynamically generated API is shown. In response to theonboarding system 20 generating the second data file 24, the second datafile 24 may be communicated to the TPS 16, which may generate the API.In this non-limiting example, the generated API may be specific to theacquirer system 15 onboarded in FIG. 2A, such that the TPS 16 isconfigured to process payment transactions of the acquirer system 15.

In one non-limiting example, and with continued reference to FIG. 2B,the consumer 12 may initiate a transaction with the merchant system 14(e.g., merchant POS device). The merchant system 14 may communicate atransaction message to the acquirer system 15 (the merchant bank of thatmerchant). The acquirer system 15 may communicate the transactionmessage to the transaction processing system (TPS) 16 associated withthe consumer's 12 payment device to request that the payment transactionbe processed. In this particular non-limiting embodiment, the acquirersystem 15 may communicate the transaction message to the augmentationsystem 25 of the TPS 16, and the augmentation system 25 may include oneor more computer systems, computer devices, software applications,and/or the like operated by or on behalf of, for example, thetransaction service provider.

The transaction message communicated to the augmentation system 25 maybe different from the transaction message described in connection withFIG. 1. The transaction message in this case may be an abbreviatedtransaction message compared to the transaction message described inconnection with FIG. 1. The abbreviated transaction message may includeless data compared to the transaction message described in FIG. 1 fromthe acquirer system 15 to the TPS 16. The abbreviated transactionmessage may contain data identifying the acquirer system 15. Theabbreviated transaction message may also include dynamic transactiondata that is different from transaction to transaction for that acquirersystem 15. For example, data associated with transaction amount,consumer information, and the like may be different for each transactionin which the acquirer system 15 is involved. However, the abbreviatedtransaction message may not include at least a portion of statictransaction data that is the same from transaction to transaction forthe acquirer system 15. For example, data such as Acquirer BIN, AcquirerCountry Code, and Acquirer Business ID may be the same for eachtransaction in which that acquirer is involved. Therefore, theabbreviated transaction message reduces the amount of data required fortransmission by the acquirer system 15 and enhances the efficiency withwhich the transaction is processed. This also enhances the accuracy oftransactions being processed by avoiding incorrect static transactiondata being transmitted in the transaction messages.

In response to receiving the abbreviated transaction message, theaugmentation system 25 may determine the acquirer system involved in thepayment transaction and augment the abbreviated transaction message byincluding at least a portion of the static transaction data therein.This augmented message may be used by the TPS 16 to generate theauthorization request communicated by the TPS 16 to the issuer system18. This authorization request generated from the abbreviatedtransaction message, the static transaction data augmented by theaugmentation system 25, and other required data from the TPS 16 mayconform to ISO 8583.

In response to the authorization request, the issuer system 18 may makean authorization decision as to whether the payment transaction is to beapproved or declined. The issuer system 18 may communicate anauthorization response containing the authorization decision to the TPS16, and the authorization response may conform to ISO 8583 in itsformat. The TPS 16 may then communicate the authorization response tothe acquirer system 15 which, in turn, communicates the authorizationresponse to the merchant system 14, which is subsequently conveyed tothe consumer 12.

Referring to FIG. 7A, another non-limiting embodiment of the first datafile 222 is shown that is associated with onboarding an issuer system 18so that the issuer system 18 may conduct payment transactions with theTPS 16. The first data file 222 may include a plurality of data entries26, and each data entry may include a plurality of values of specificdata parameters 30. In other words, the first row of the first data file222 table includes the specific data parameters 30, which are columnheadings of the table, and subsequent rows are data entries 26 in thetable. Each data entry 26 includes client data 28 associated with eachspecific data parameter 30. As one non-limiting example from the firstdata file 222 shown in FIG. 7A, “Consumer ID” is a specific dataparameter 30, and in the first data entry, the client data 28 associatedwith “Consumer ID” is “0001”.

Referring to FIG. 7B, a non-limiting embodiment of the second data file224 converted from the first data file 222 is shown. The second datafile 224 includes at least a portion of the data from the first datafile 222. For example, the data associated with “Consumer ID” from thefirst data file 222 is included in the second data file 224; however,this data has been relabeled “Client's Consumer ID”. Moreover, the dataassociated with “PAN” from the first data file 222 is included in thesecond data file 224 and relabeled as “ISO 8583 Data Field 2”. New datalabeled “Client ID” in the second data file 224 was not previouslyincluded in the first data file 222 and constitutes an identifierassociated with the issuer system 18 (a client identifier) communicatingthe first data file 222 (e.g., the transaction service provideridentifies that specific issuer system as “624”). In this way, thesecond data file 224 includes at least a portion of the data from thefirst data file 222, although that data may be rearranged, reformatted,relabeled, or otherwise edited.

With continued reference to FIGS. 3A, 3B, 7A, and 7B, previouslydescribed examples contemplated onboarding an acquirer system 15 withthe TPS and an issuer system 18 with a TPS 16. In the non-limitingembodiment of the first data file 122 in FIGS. 3A and 3B, for example,the data is associated with a merchant system 14 and/or an acquirersystem (not shown) to be onboarded with the TPS 16. In the non-limitingembodiment of the first data file 222 in FIGS. 7A and 7B, for example,the data is associated with an issuer system 18 to be onboarded with theTPS 16. However, it will be appreciated that the system 19 may beutilized in any suitable onboarding application in which a second datafile has a format different from the first data file of the client.

Referring to FIG. 8, one non-limiting embodiment or aspect of a method150 for dynamic development of an API is shown. At a first step 152, theonboarding system may receive the first data file including a pluralityof data entries, each data entry comprising the plurality of values ofspecific data parameters. At a second step 154, the onboarding systemmay generate an API configured to receive the data associated with atransaction message. At a third step 156, the onboarding system maydisplay the second GUI, such that a field displayed by the second GUI isconfigured to receive the data associated with each specific dataparameter of the plurality of specific data parameters.

Referring to FIG. 9, one non-limiting embodiment or aspect of a method160 for generating the API is shown. At a first step 162, a dataagnostic template is provided including the first graphical userinterface, the data agnostic template including the plurality of dataagnostic parameters, each data agnostic parameter comprising a templatefield, each template field configured to receive a specific data entryassociated with a specific data parameter of the plurality of specificdata parameters. At a second step 164, for each specific data parameterof the plurality of specific data parameters, each template field isassigned with a corresponding specific data entry associated with thespecific data parameter. At a third step 166, the second GUI isconfigured by associating the at least one display parameter with eachspecific data parameter of the plurality of specific data parameters.

In a further, non-limiting embodiment or aspect, a computer programproduct for dynamic development of an API includes at least onenon-transitory computer readable medium including program instructionsthat, when executed by at least one processor, cause the at least oneprocessor to execute one of the previously-described systems and/ormethods. The at least one processor may include the onboarding system20.

The computer program product may include a plurality ofcomputer-readable media, such as a first computer-readable medium and asecond computer-readable medium. The first computer-readable medium maybe located at the entity controlling the onboarding system 20. Thesecond computer-readable medium may be located local to or remote fromthe entity controlling the onboarding system 20. The remote secondcomputer-readable medium may be located at the system communicating thefirst data file to the onboarding system 20 (e.g., issuer system,merchant system, acquirer system, and the like).

Although the disclosure has been described in detail for the purpose ofillustration based on what is currently considered to be the mostpractical and preferred embodiments, it is to be understood that suchdetail is solely for that purpose and that the disclosure is not limitedto the disclosed embodiments, but, on the contrary, is intended to covermodifications and equivalent arrangements that are within the spirit andscope of the appended claims. For example, it is to be understood thatthe present disclosure contemplates that, to the extent possible, one ormore features of any embodiment can be combined with one or morefeatures of any other embodiment.

What is claimed is:
 1. A method for processing a transaction associated with an onboarded acquirer system, comprising: onboarding, with at least one processor, a first acquirer system associated with an acquirer by: receiving, with at least one processor and from the first acquirer system, a first data file comprising a plurality of data entries, wherein the plurality of data entries comprise static transaction data associated with the first acquirer system; and generating, with at least one processor, a second data file having a predetermined format, the second data file comprising at least a portion of the static transaction data; and storing, with at least one processor, the second data file; receiving, with at least one processor and from the first acquirer system, an abbreviated transaction message associated with a payment transaction, wherein the abbreviated transaction message comprises dynamic data associated with the payment transaction; in response to receiving the abbreviated transaction message, determining, with at least one processor, that the acquirer system associated with the payment transaction is the first acquirer system; generating, with at least one processor, an authorization request, wherein the authorization request comprises at least a portion of the dynamic data from the abbreviated transaction request and at least a portion of the static transaction data from the stored second data file; and communicating, with at least one processor, the authorization request to an issuer system to cause the issuer system to generate an authorization decision associated with the payment transaction.
 2. The method of claim 1, wherein the static transaction data comprises an identifier associated with the first acquirer system, and the abbreviated transaction message comprises the identifier.
 3. The method of claim 2, wherein the acquirer system associated with the payment transaction is determined based on the identifier from the abbreviated transaction message.
 4. The method of claim 1, wherein the dynamic transaction data comprises transaction data that can be different from transaction to transaction for the first acquirer system.
 5. The method of claim 1, wherein the static transaction data comprises transaction data that does not change for the first acquirer system from transaction to transaction.
 6. The method of claim 1, wherein the abbreviated transaction message does not comprise at least a portion of the static data from the stored second data file.
 7. The method of claim 1, wherein the dynamic data from the abbreviated transaction request and the static transaction data from the stored second data file comprise at least one data element associated with data elements defined by ISO
 8583. 8. A system for processing a transaction associated with an onboarded acquirer system comprising at least one processor programmed or configured to: onboard a first acquirer system associated with an acquirer by: receiving, from the first acquirer system, a first data file comprising a plurality of data entries, wherein the plurality of data entries comprise static transaction data associated with the first acquirer system; and generating a second data file having a predetermined format, the second data file comprising at least a portion of the static transaction data; and storing the second data file; receive, from the first acquirer system, an abbreviated transaction message associated with a payment transaction, wherein the abbreviated transaction message comprises dynamic data associated with the payment transaction; in response to receiving the abbreviated transaction message, determine that the acquirer system associated with the payment transaction is the first acquirer system; generate an authorization request, wherein the authorization request comprises at least a portion of the dynamic data from the abbreviated transaction request and at least a portion of the static transaction data from the stored second data file; and communicate the authorization request to an issuer system to cause the issuer system to generate an authorization decision associated with the payment transaction.
 9. The system of claim 8, wherein the static transaction data comprises an identifier associated with the first acquirer system, and the abbreviated transaction message comprises the identifier.
 10. The system of claim 9, wherein the acquirer system associated with the payment transaction is determined based on the identifier from the abbreviated transaction message.
 11. The system of claim 8, wherein the dynamic transaction data comprises transaction data that can be different from transaction to transaction for the first acquirer system.
 12. The system of claim 8, wherein the static transaction data comprises transaction data that does not change for the first acquirer system from transaction to transaction.
 13. The system of claim 8, wherein the abbreviated transaction message does not comprise at least a portion of the static data from the stored second data file.
 14. The system of claim 8, wherein the dynamic data from the abbreviated transaction request and the static transaction data from the stored second data file comprise at least one data element associated with data elements defined by ISO
 8583. 15. A computer program product for processing a transaction associated with an onboarded acquirer system, the computer program product comprising at least one non-transitory computer-readable medium including one or more instructions that, when executed by at least one processor, cause the at least one processor to: onboard a first acquirer system associated with an acquirer by: receiving, from the first acquirer system, a first data file comprising a plurality of data entries, wherein the plurality of data entries comprise static transaction data associated with the first acquirer system; and generating a second data file having a predetermined format, the second data file comprising at least a portion of the static transaction data; and storing the second data file; receive, from the first acquirer system, an abbreviated transaction message associated with a payment transaction, wherein the abbreviated transaction message comprises dynamic data associated with the payment transaction; in response to receiving the abbreviated transaction message, determine that the acquirer system associated with the payment transaction is the first acquirer system; generate an authorization request, wherein the authorization request comprises at least a portion of the dynamic data from the abbreviated transaction request and at least a portion of the static transaction data from the stored second data file; and communicate the authorization request to an issuer system to cause the issuer system to generate an authorization decision associated with the payment transaction.
 16. The computer program product of claim 15, wherein the static transaction data comprises an identifier associated with the first acquirer system, and the abbreviated transaction message comprises the identifier.
 17. The computer program product of claim 16, wherein the acquirer system associated with the payment transaction is determined based on the identifier from the abbreviated transaction message.
 18. The computer program product of claim 15, wherein the dynamic transaction data comprises transaction data that can be different from transaction to transaction for the first acquirer system.
 19. The computer program product of claim 15, wherein the static transaction data comprises transaction data that does not change for the first acquirer system from transaction to transaction.
 20. The computer program product of claim 15, wherein the abbreviated transaction message does not comprise at least a portion of the static data from the stored second data file. 